Add aten::complex.out support for export and CPU execution - #24330

• Build Linux CUDA Wheels / pytorch/executorch / build-manywheel-py3_11-cuda13_2 (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
• Build Linux CUDA Wheels / pytorch/executorch / upload / upload-manywheel-py3_11-cuda13_2 (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  Unable to download artifact(s): Artifact not found
• Build Linux Wheels / pytorch/executorch / build-manywheel-py3_11-cpu (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
• Build Linux Wheels / pytorch/executorch / upload / upload-manywheel-py3_11-cpu (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  Unable to download artifact(s): Artifact not found

👉 Rebase onto the `viable/strict` branch to avoid these failures

• Test QNN Backend / test-qnn / test-backend-linux (qnn, models) / linux-job (gh) (trunk failure)
  curl: (22) The requested URL returned error:
• Test QNN Backend / test-qnn / test-backend-linux (qnn, operators) / linux-job (gh) (trunk failure)
  curl: (22) The requested URL returned error:
• Test QNN Windows MSVC build / build-qnn-windows-arm64 (gh) (trunk failure)
• Test QNN Windows MSVC build / build-qnn-windows-x64 / windows-job (gh) (trunk failure)

PR Review: #24330

Summary

This PR adds a portable complex.out kernel. It also maps edge dtypes to complex32 and adds a temporary Core ATen verifier exemption, so torch.complex(real, imag) can export with default to_edge() and run on CPU.

Three reviewers looked at the PR independently, and all three found the same build-list gap. There is also a design question about how wide the verifier exemption reaches, plus some smaller test and coverage gaps.

Infrastructure

• shim_et/xplat/executorch/build/build_variables.bzl:108: kernels/portable/cpu/op_complex.cpp is not in PORTABLE_KERNELS_SRCS (all 3 reviewers; I confirmed it).
  • Why CI won't catch it: kernels/portable/CMakeLists.txt globs cpu/*.cpp, so normal builds work.
  • What breaks: tools/cmake/Codegen.cmake:445-446 builds selected_portable_kernels from _portable_kernels__srcs, and that list comes from this file.
  • Trigger: a selective or dtype-selective CMake build that selects aten::complex.out. The generated registration refers to torch::executor::native::complex_out, but nothing compiles it, so the link should fail with an undefined symbol. I did not build this.
  • Fix: add "kernels/portable/cpu/op_complex.cpp", between op_clone.cpp and op_constant_pad_nd.cpp. Fix this →

API Design

• exir/verification/verifier.py:147-149: the exemption is hard-coded and applies to every user.
  • Scope: _get_core_aten_ops_exception_list is used by both the ATen and Edge verifiers. Every to_edge() call now accepts aten.complex.default, whatever the target runtime. That includes delegate-only runtimes, where no backend claims the op.
  • Failure moves later: those users used to get a clear Core ATen error at export time. Now they get a missing-kernel error at runtime, or a link error in a selective build. The opt-in EdgeCompileConfig(_core_aten_ops_exception_list=[...]) path exists for this case, and its error message tells users to check that a kernel exists first.
  • Removal is untracked: the other entries carry TODO(T…) task IDs. This TODO has no issue, no link to the upstream PyTorch PR, and no version gate, so nothing will flag it as dead code once PyTorch tags complex as core.
  • Options:
    • Gate the exemption, for example only add it when torch.Tag.core not in torch.ops.aten.complex.default.tags.
    • At minimum, link the upstream PR or issue in the TODO.
    • Whether to keep it global or make it opt-in is a call for the maintainers.

Testing

• No exir-level test.
  • The only end-to-end coverage is extension/pybindings/test/test_pybindings.py:1841, and it only runs when native bindings are built.
  • Nothing in exir/verification/test checks that to_edge() accepts torch.complex, or that it keeps working after the exemption is removed.
• kernels/test/op_complex_test.cpp:218-238 (NonDefaultDimOrder) uses a pattern no other kernel test uses.
  • It loops over three cases inside one TEST_F and resets the fixture with context_ = {};. No other kernel test does this.
  • If one case fails, the output doesn't say which case it was.
  • Split it into three TEST_Fs, as the sibling tests do.
• ComplexHalf mismatches will abort instead of printing a diff.
  • runtime/core/exec_aten/testing_util/tensor_util.cpp:334 only handles ET_FORALL_COMPLEX_TYPES, which doesn't include ComplexHalf.
  • So if OpComplexOutTest.Half ever fails, gtest's printer reaches ET_CHECK_MSG(false, "Unhandled dtype ...") and aborts the process instead of reporting the mismatch.
  • This is the first op test that compares ComplexHalf tensors. Switching that line to ET_FORALL_COMPLEXH_TYPES (already defined at scalar_type_util.h:363) fixes it.

Code Quality

• exir/dialects/edge/dtype/supported.py:30: complex32 support only covers the case where the result is a graph output. Low confidence: I did not run it.
  • Adding torch.complex32 here makes ops with no edge.yaml entry, including complex.default, accept ComplexHalf through the fallback at exir/dialects/edge/_ops.py:230-240.
  • edge.yaml has no ComplexHalf entries at all.
  • So in an FP16 model, if the complex32 result feeds an op whose constraints come from edge.yaml, to_edge should still fail the edge dtype check. Examples are clone, view_copy and permute_copy.
  • Either narrow the PR description's FP16→complex32 claim, or regenerate the spec and add a test where the complex32 output is consumed by another op.
• kernels/portable/cpu/op_complex.cpp:38-44: the dim-order check is stricter than in sibling binary kernels.
  • It requires tensor_is_default_dim_order on all three tensors. Ops like op_atan2.cpp use tensors_have_same_dim_order(a, b, out) instead.
  • So a channels-last export passes to_edge and then fails with InvalidArgument at runtime.
  • The PR description says this is intentional. Unless there's a reason the broadcast path can't handle matching non-default dim orders, tensors_have_same_dim_order would match the other kernels.

Recommendation

Request Changes

The only blocking item is the missing PORTABLE_KERNELS_SRCS entry, which is a one-line fix. The verifier exemption's scope and how it will be removed need a maintainer decision. The rest are minor.